home *** CD-ROM | disk | FTP | other *** search
- Path: informatik.tu-muenchen.de!fischerj
- From: fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: need help on A1200/030 board programming
- Date: 12 Mar 1996 18:00:21 GMT
- Organization: Technische Universitaet Muenchen, Germany
- Distribution: world
- Message-ID: <4i4e3l$8oo@sunsystem5.informatik.tu-muenchen.de>
- References: <4gb9ao$104@sunsystem5.informatik.tu-muenchen.de> <1189.6628T141T1560@wr.com.au> <38232664@kone.fipnet.fi> <772.6632T572T2649@manawatu.gen.nz> <4h4ek7$lp1@sunsystem5.informatik.tu-muenchen.de> <1393.6635T1366T2221@manawatu.gen.nz>
- NNTP-Posting-Host: hphalle10.informatik.tu-muenchen.de
- Originator: fischerj@hphalle10.informatik.tu-muenchen.de
-
-
- In article <1393.6635T1366T2221@manawatu.gen.nz>, kurg@manawatu.gen.nz (Damon Davies) writes:
- |> Organization: PlaNet (NZ) Manawatu, Palmerston Nth, New Zealand +64 6 357-9245
- |> Lines: 41
- |> Message-ID: <1393.6635T1366T2221@manawatu.gen.nz>
- |> References: <4gb9ao$104@sunsystem5.informatik.tu-muenchen.de>
- |> <1189.6628T141T1560@wr.com.au> <38232664@kone.fipnet.fi>
- |> <772.6632T572T2649@manawatu.gen.nz> <4h4ek7$lp1@sunsystem5.informatik.tu-muenchen.de>
- |> NNTP-Posting-Host: kurg.manawatu.gen.nz
- |> Mime-Version: 1.0
- |> Content-Type: text/plain; charset=iso-8859-1
- |> Content-Transfer-Encoding: 8bit
- |> X-Newsreader: THOR 2.21 (Amiga;TCP/IP)
- |>
- |> Juergen writes:
- |>
- |> >In article <772.6632T572T2649@manawatu.gen.nz>, kurg@manawatu.gen.nz (Damon
- |> >Davies) writes:
- |> >|> >You dont have to "recognise" FAST-ram, just dont force stuff
- |> >|> >into CHIP-ram which does not need to be there, ie. only
- |> >|> >gfx data, samples, display memory etc.
- |> >|>
- |> >|> >-- _
- |> >|> >a Stellar programmer _ //
- |> >|> >"Amiga - back for the future" \X/
- |> >|>
- |> >|> Just an ellaboration:
- |> >|>
- |> >|> This is how you do it in assembler "Section TheCode,code" will put the
- |> >|> code in fast ram preferably, but in chip if there is no fast."Section
- |> >|> TheCode,code_f" will put the code in fast only! and fail if there is none.
- |>
- |> >Forcing code to fast is imho nonsense.
- |>
- |> >I only use alloc(fast) one time:
- |>
- |> > p=alloc(fast)
- |> > if fail (p=alloc(chip); chip=true)
- |>
- |> > so my code will know if it has to copy to chip if I use a 0-cpu-pass
- |> > routine.
- |>
- |> >can't see any other reason for using the memf_fast flag...
- |>
- |> mmm, you should learn too read Juergen, what I was pointing out is that
- |> there was an assembly directive that put code in fast PREFERABLY and in
- |> chip OTHERWISE.
-
- don't know what you said, but I refered to (look up)
- "TheCode,code_f will put the code in fast only!".
-
- A directive that will "put code in fast PREFERABLY and in chip OTHERWISE"
- is not needed, this is system default.
-
- |> You can do the same thing with the exec Alloc() and AllocVec() commands,
- |> instead of specifying MEMF_CHIP or MEMF_FAST in the flags, you may put
- |> MEMF_ANY and it will do as I describe above. So the code you describe is a
- ^--- i.e. 0.
-
- |> bit silly really, if you now how to use exec.... :^|
-
- why silly. what would "now how to use exec" do in the case I described ?
- imho mine is most transparen, shortest, best way :)
-
- |>
- |> Damon.
- |>
- |>
- ------------------------------------------------------------------------
- fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) =:)
-
-